-
Notifications
You must be signed in to change notification settings - Fork 0
Conversation
|
Am 28.09.2018 um 08:26 schrieb Thomas Kreitler:
> 'Building libxcb crashes bee'
How does it crash / what crashes?
It just hang on *bohemianrapsody*, when creating the build archive.
libxcb-1.12-0 did build, and testing 1.13 would require to install xcb-proto >= 1.13.
I built xcb-proto 1.13 yesterday.
|
Was it reproducible? |
Am 01.10.2018 um 07:58 schrieb Thomas Kreitler:
> It just hang on *bohemianrapsody*, when creating the build archive.
Was it reproducible?
Yes.
|
Then I suspect that pbzip choked for some reason, and guess the build succeeded on a machine w less cores? |
On 10/01/18 09:36, Thomas Kreitler wrote:
Then I suspect that pbzip choked for some reason, and guess the build
succeeded on a machine w less cores?
Here is the output, from a run, where it didn’t finish. The `defunct` let
me to believe that something crashed.
```
pmenzel 99950 0.0 0.0 4132 672 pts/12 S+ 18:18 0:00 | \_ /usr/bin/time sudo BEE_TMP_TMPDIR=/dev/shm BEE_TMP_BUILDROOT=/dev/shm/bee-root BEE_MAKEFLAGS=-j110 ./libxcb.be0 -c -
root 99951 0.0 0.0 46312 3108 pts/12 S+ 18:18 0:00 | \_ sudo BEE_TMP_TMPDIR=/dev/shm BEE_TMP_BUILDROOT=/dev/shm/bee-root BEE_MAKEFLAGS=-j110 ./libxcb.be0 -c -c
root 99952 0.0 0.0 24812 3872 pts/12 S+ 18:18 0:00 | \_ /bin/bash /usr/bin/beesh ./libxcb.be0 -c -c
root 27139 0.0 0.0 24812 2344 pts/12 S+ 18:20 0:00 | \_ /bin/bash /usr/bin/beesh ./libxcb.be0 -c -c
root 27140 0.0 0.0 24812 2468 pts/12 S+ 18:20 0:00 | \_ /bin/bash /usr/bin/beesh ./libxcb.be0 -c -c
root 27142 0.0 0.0 24284 3360 pts/12 S+ 18:20 0:00 | | \_ /bin/bash /usr/libexec/bee/bee.d/bee-cache print-conflicts libxcb-1.13-0.x86_64 --tmpinstall /de
root 27146 0.0 0.0 24284 2132 pts/12 S+ 18:20 0:00 | | \_ /bin/bash /usr/libexec/bee/bee.d/bee-cache print-conflicts libxcb-1.13-0.x86_64 --tmpinstall
root 27149 99.3 0.0 579524 516028 pts/12 R+ 18:20 0:53 | | | \_ grep --file=/dev/fd/63 /dev/fd/62
root 27151 0.0 0.0 0 0 pts/12 Z+ 18:20 0:00 | | | | \_ [bee-cache] <defunct>
root 27153 0.0 0.0 24284 2004 pts/12 S+ 18:20 0:00 | | | | \_ /bin/bash /usr/libexec/bee/bee.d/bee-cache print-conflicts libxcb-1.13-0.x86_64 --tm
root 27156 0.0 0.0 4268 672 pts/12 S+ 18:20 0:00 | | | | \_ /usr/bin/beeflock --shared /var/cache/bee/bee-cache/INVENTORY sort -m -u -r -k8
root 27164 0.0 0.0 17136 2480 pts/12 S+ 18:20 0:00 | | | | \_ sort -m -u -r -k8 -k1 /var/cache/bee/bee-cache/INVENTORY /dev/shm/bee-root/l
root 27150 0.0 0.0 17088 2308 pts/12 S+ 18:20 0:00 | | | \_ grep -v -E ^libxcb-[^-]+-[^-]+
root 27147 0.0 0.0 14368 760 pts/12 S+ 18:20 0:00 | | \_ cut -d -f1,8-
root 27141 0.0 0.0 33132 880 pts/12 S+ 18:20 0:00 | \_ sort -k1 -u
```
I started a build again after that, and let it run. It finished after an
hour, which is strange for a 13 MB build archive.
```
[…]
[BEE] -> saving bee-file libxcb.be0 ..
[BEE] /src/mariux/beeroot/bee-files/libxcb-1.13-0.bee
‘/home/pmenzel/bee-files/./libxcb.be0’ -> ‘/src/mariux/beeroot/bee-files/libxcb-1.13-0.bee’
→ It hangs here.
[BEE] -> saving build environment..
[BEE] /src/mariux/beeroot/build-archives/libxcb-1.13-0.x86_64.beebuild.tar.bz2
[BEE] ===================================================================
[BEE] build summary:
[BEE]
[BEE] download directory ${F}: /dev/shm/bee-root/libxcb/files
[BEE] source directory ${S}: /dev/shm/bee-root/libxcb/libxcb-1.13-0/source
[BEE] build directory ${B}: /dev/shm/bee-root/libxcb/libxcb-1.13-0/build
[BEE] image directory ${D}: /dev/shm/bee-root/libxcb/libxcb-1.13-0/image
[BEE]
[BEE] bee-file: /src/mariux/beeroot/bee-files/libxcb-1.13-0.bee
[BEE] pkg-file: /src/mariux/beeroot/packages/libxcb-1.13-0.x86_64.bee.tar.bz2
[BEE] build-archive: /src/mariux/beeroot/build-archives/libxcb-1.13-0.x86_64.beebuild.tar.bz2
[BEE] ===================================================================
3637.96user 113.16system 59:29.70elapsed 105%CPU (0avgtext+0avgdata 64376064maxresident)k
8inputs+94232outputs (0major+15348861minor)pagefaults 0swaps
pmenzel@bohemianrhapsody:~/bee-files> ls -lh /src/mariux/beeroot/build-archives/libxcb-1.13-0.x86_64.beebuild.tar.bz2
-rw-r--r-- 1 root root 13M Sep 27 19:18 /src/mariux/beeroot/build-archives/libxcb-1.13-0.x86_64.beebuild.tar.bz2
pmenzel@bohemianrhapsody:~/bee-files> ls -lh /src/mariux/beeroot/build-archives/libxcb-1.13-0.x86_64.beebuild.tar.bz2 /src/mariux/beeroot/packages/libxcb-1.13-0.x86_64.bee.tar.bz2 /src/mariux/beeroot/bee-files/libxcb-1.13-0.bee
-rw-r--r-- 1 root root 2.6K Sep 27 18:20 /src/mariux/beeroot/bee-files/libxcb-1.13-0.bee
-rw-r--r-- 1 root root 13M Sep 27 19:18 /src/mariux/beeroot/build-archives/libxcb-1.13-0.x86_64.beebuild.tar.bz2
-rw-r--r-- 1 root root 9.8M Sep 27 18:20 /src/mariux/beeroot/packages/libxcb-1.13-0.x86_64.bee.tar.bz2
```
I am able to reproduce it right now on *bohemianrapsody*. I’ll just
wait an hour.
|
With
|
The bee problem also exists with
|
45f2c5a
to
efdf3be
Compare
I don't know the stat of this pull request, ( conflict, "not ready for merge" ). I just found, that our current versions of
|
When |
When I update libxcb (only) to libxcb-1.13-0, restart the X-Server by log-out/log-in, then use the mouse wheel to scroll a long firefox page, the mouse wheel and the mouse buttons suddenly become unresponsive (e.g. after 30 seconds activity for 10 seconds). Typing any key immediately unfreezes the mouse. EDIT: clarified, that the X-Server needs to be restarted and that mouse wheel scrolling is the trigger. |
Why so harsh? Jepp, it's just a N^2 thingy and we should replace it with something hash-based I guess. |
Am 08.10.2018 um 16:37 schrieb Donald Buczek:
`sudo bee update libxcb` takes forever ( longer, that I ever had the
patience to wait ) libxcb contains 10908 files. In print_conflicts()
from /usr/libexec/bee/bee.d/bee-cache, `print_conflicting_files
"${pkg}" | cut -d ' ' -f8- | sed -e 's,.*, &$,' build a list of 8249
patterns, which are applied to the output of
`tmp_merge_install_inventory_files "${TMPINSTALL[@]}" ` which
contains 339184 files. With the 8249 patterns, the grep will spit out
about 10 lines a seconds, so my estimate for that step alone is about
15 minutes, but I'm sure I waited longer for `bee update` to
complete.
In my experience it took around one hour each time, and the problem was
also hit when building. See the comments. (Strangely using strace
influenced the behavior.)
When `print_conflicts` is disabled, the `bee update` takes no time at
all. The bee cache code is ugly and a big abuse of grep.
Yeah, we should open a bee issue.
|
bee issue: mariux64/bee#26 |
Am 08.10.2018 um 17:07 schrieb Donald Buczek:
When I update libxcb (only) to libxcb-1.13-0 and use the mouse and the mouse wheel a bit in the browser, the mouse wheel and the mouse button suddenly become unresponsive (e.g. after 30 seconds activity for 10 seconds). Downgrading to libxcb-1.12-0 and everyhing is fine. Switched multiple times and verified the effect.
Maybe it is fixed in libxcb 1.13.1, which I overlooked or wasn’t
released yet, when I worked on that.
… commit 8287ebd7b752c33b0cabc4982606fe4831106f7e
Author: Uli Schlachter ***@***.***>
Date: Thu Sep 27 14:04:17 2018 +0200
Release libxcb 1.13.1
commit bbda345a718ff73086437e51f03fcbb73e4365b9
Author: Erik Kurzinger ***@***.***>
Date: Mon Aug 20 12:06:25 2018 -0700
don't flag extra reply in xcb_take_socket
If any flags are specified in a call to xcb_take_socket,
they should only be applied to replies for requests sent
after that function returns (and until the socket is
re-acquired by XCB).
Previously, they would also be incorrectly applied to the
reply for the last request sent before the socket was taken.
For instance, in this example program the reply for the
GetInputFocus request gets discarded, even though it was
sent before the socket was taken. This results in the
call to retrieve the reply hanging indefinitely.
static void return_socket(void *closure) {}
int main(void)
{
Display *dpy = XOpenDisplay(NULL);
xcb_connection_t *c = XGetXCBConnection(dpy);
xcb_get_input_focus_cookie_t cookie = xcb_get_input_focus_unchecked(c);
xcb_flush(c);
uint64_t seq;
xcb_take_socket(c, return_socket, dpy, XCB_REQUEST_DISCARD_REPLY, &seq);
xcb_generic_error_t *err;
xcb_get_input_focus_reply(c, cookie, &err);
}
In practice, this has been causing intermittent KWin crashes when
used in combination with the proprietary NVIDIA driver such as
https://bugs.kde.org/show_bug.cgi?id=386370 since when Xlib fails to
retrieve one of these incorrectly discarded replies it triggers
an IO error.
Signed-off-by: Erik Kurzinger ***@***.***>
Signed-off-by: Uli Schlachter ***@***.***>
|
I've rebased to master and fixed the conflicts. Also I added nvidia 390.87 and a script for easy install for testing. Everything is in the update-graphics-and-x-stack-v2 branch, if you want to work from there, you can reset this PRs branch to update-graphics-and-x-stack-v2. X-Server comes up on theinternet and everything looks fine. But, unfortunately, the mouse wheel problem is still present. I'll try libxcb1.13.1. |
Problem persists with libcbx1.13.1 😞 |
efdf3be
to
58418a3
Compare
58418a3
to
da943ef
Compare
Change-log from [announcement][1]: > Benjamin Gaignard (2): > tests/modetest: Add atomic support > tests/util: Add support for stm module > > Christian König (7): > amdgpu: stop using the hash table for fd_tab > amdgpu: add handle table implementation v2 > amdgpu: use handle table for KMS handles > amdgpu: use handle table for flink names > amdgpu: remove the hash table implementation > amdgpu: always add all BOs to handle table > amdgpu: fix off by one in handle_table_insert > > Junwei Zhang (5): > amdgpu: add bo from user memory to handle table > amdgpu: add a function to find bo by cpu mapping (v2) > tests/amdgpu: add test for finding bo by CPU mapping > amdgpu: free flink bo in bo import > amdgpu: add a function to create amdgpu bo internally (v4) > > Kristian H. Kristensen (1): > Bump to version 2.4.94 > > Likun Gao (1): > amdgpu: Disable deadlock test suite for RV > > Michel Dänzer (2): > amdgpu: Use uint32_t i in amdgpu_find_bo_by_cpu_mapping > amdgpu: Eliminate void* arithmetic in amdgpu_find_bo_by_cpu_mapping > > Mike Lothian (1): > libdrm: Fix amdgpu build failure > > Rob Clark (2): > freedreno: don't leak stateobj rb refs > freedreno: fix use-after-free with stateobj rb's > > Rodrigo Vivi (1): > intel: Add a new CFL PCI ID. > > Tanmay Shah (1): > libdrm: add msm drm uapi header [1]: https://lists.freedesktop.org/archives/dri-devel/2018-August/187286.html
Mesa 18.2.1 requires this version. checking for WAYLAND_EGL... no configure: error: Package requirements (wayland-egl-backend >= 3) were not met: No package 'wayland-egl-backend' found
libxcb 1.13 requires this version.
Change-logs are available online. 1. https://www.mesa3d.org/relnotes/18.2.0.html 2. https://www.mesa3d.org/relnotes/18.2.1.html Built with the command below. sudo BEE_TMP_TMPDIR=/dev/shm BEE_TMP_BUILDROOT=/dev/shm/bee-root BEE_MAKEFLAGS='-j120' prun python ./mesalib.be0 -c This fixes the error below. configure: error: Python mako module v0.8.0 or higher not found Python environment: $ prun python python --version Python 2.7.15
Fix a [build error][1]. [1]: https://bugs.freedesktop.org/show_bug.cgi?id=108120
Address the warning below. configure: WARNING: unrecognized options: --enable-texture-float
Change-log from the announcement: > Bhavi Dhingra (1): > XcmsLookupColor: fully initialize XColor structs passed to _XColor_to_XcmsRGB > > Matt Turner (1): > libX11 1.6.7 > > Michel Dänzer (2): > poll_for_response: Call poll_for_event again if xcb_poll_for_reply fails > poll_for_event: Allow using xcb_poll_for_queued_event This might fix [Bug 108301 - Unresponsive mouse wheel and buttons after update to 1.13{,.1}][1]. [1]: https://bugs.freedesktop.org/show_bug.cgi?id=108301
0b81c1e
to
e9abc48
Compare
On Nvidia systems Linux kernel 4.14.74 is needed, as the new Nvidia driver is only built for that version. My tests were successful. GDM starts up and no scrolling problem could be reproduced using Firefox and https://github.molgen.mpg.de/mariux64/bee-files/. @donald, it’d be great if you tested this again on your system. |
I tested it with the user molgen on theinternet, and couldn’t reproduce the problem in Firefox. The bug seems to have been fixed in libX11 1.6.7. |
a2a2be6
to
6761275
Compare
This is good to go. Systems using the proprietary Nvidia driver need to be reboot with Linux 4.14.74. The other systems do not have a problem, and can be easily updated. |
6761275
to
4c55e51
Compare
I split out the X.Org X Server 1.20.x update into the separate merge/pull request #939. This should be fine to go in, and does not require a restart of the system, which might be required for the proprietary Nvidia driver. |
|
||
sudo bee update wayland-1.16.0-0 | ||
sudo bee install xcb-proto-1.13-0 | ||
sudo bee update libxcb-1.13-0.x86_64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was the wrong version, and libxcb-1.13.1-0.x86_64
should have been installed.
$ sudo bee remove libxcb-1.13-0.x86_64
removing libxcb-1.13-0.x86_64 ..
$ sudo bee install libxcb-1.13.1-0.x86_64
installing /src/mariux/beeroot/packages/libxcb-1.13.1-0.x86_64.bee.tar.bz2 ..
Update libdrm, and Mesa. The Mesa update required libxcb and libX11 to be updated.
Install with
sudo ./scripts/update-graphics-and-x-stack.sh
.Tested on keineahnung (i915 and modesetting DDX), inbetweenmove (AMDGPU) and hmmjaaeh (proprietary Nvidia). With libX11 1.6.7 @donald’s mouse problem couldn’t be reproduced.